It has been agreed in RAN2 that the beam level reporting is supported in NR. Specifically, it has been agreed that:                Beam measurement (based on New Radio-Synchronization Signal (NR-SS) and Channel State Information-Reference Signal (CSI_RS)) can be included in the measurement report and can be configured by the network (i.e., network configures the user equipment (UE) to report beam identifier only, beam measurement result and identifier, or no beam reporting)        Measurement quantities can be configured by the network for beam measurement reporting. RAN1 to confirm the measurement quantities supported.        For selection of x synchronization signal (SS) blocks to be included in the measurement report for each cell: x can be configured separately from N (N used in cell quality derivation).        Measurement quantity to be reported for beam measurements can be the same as (cell) trigger quantity or both RSRP/RSRQ.        For measurement events based on NR-SS, in each cell the best SS block is reported and up to x−1 next highest measured SS blocks above the absolute threshold. Threshold is the same as that used for cell quantity derivation.        For measurement events based on CSI-RS, in each cell the best CSI-RS is reported and up to y−1 next highest measured CSI-RS above the absolute threshold. Threshold is the same as that used for cell quality derivation.        The beam level information (beam IDS and/or available measurements results of primary cell (PCell)/primary secondary cell (PSCell) and secondary cell (SCell) is included in the measurement report if the network has configured the UE to do so.Based on these agreements, for an event triggered measurement report, the UE shall report the beam level measurements of PCell, PSCell, SCell, and cells in the triggeredCellsList.        
Further, beam related measurement quantities to be reported for the cells in triggeredCellsList can be configured (independent of the measurement quantities to be reported for the cells) as follows: Beam index only, Beam index and beam RSRP, Beam index and beam RSRQ, or Beam index and beam signal-to-interference-plus-noise ratio (SINR). In each cell the best SS block/CSI-RS is always included in the measurement report and up to x−1/y−1 next highest measured SS blocks/CSI-RS is included in the measurement report.
Additionally, there will be support for periodic measurement reporting in NR. Specifically, the following has been agreed in RAN2:                The current beam report agreements (network configures the UE to report beam identifier only, beam measurement result and identifier, or no beam reporting) applies to both event-triggered reports and periodical reports.        A single periodical measurement configuration can be configured to report SS based measured results or CSI-RS based measured results (not both).        The UE is required to report all applicable cell up to maxCellReport for periodical measurement, where the applicable cells are defined as any neighbour cells detected on the associated frequency except for the cell in black cell list.Based on these agreements, the periodic measurement reports will be based on only one RSType that is configured in the corresponding reportConfig. Also, it has been agreed that the beam level measurements are also included in the measurement report.        
In LTE, the triggerQuantity parameter, part of the reporting configuration (reportConfig), is not only used to indicate which quantity shall be used for event triggered reporting such as, for example, either RSRP, RSRQ or SINR. In addition, it may also be used for periodical reporting. In addition to this parameter, reportConfig also contains a parameter called reportQuantity, used to indicate which quantities shall be included in the measurement report. In other words, network may configure the UE to report more quantities than what is being used for triggering the event.
If the triggerQuantity is configured as RSRP and the reportQuantity is configured as sameAsTriggerQuantity, then the UE shall report the RSRP values. If the triggerQuantity is configured as RSRQ and the reportQuantity is configured as sameAsTriggerQuantity, then the UE shall report the RSRQ values. Additionally, the reportQuantity can be configured as both, leading to reporting of both RSRP and RSRQ. In Release-13, additional SINR based reporting were also introduced.
There currently exist certain challenge(s). Based on the above agreements for NR, the network may configure a UE to include beam level measurement information (i.e., only beam indexes or beam indexes with measurement result(s)) for periodic measurement reporting as well as event triggered measurement reports. It has already been agreed that the UE shall include the best beam for each cell and up to X−1 strongest beams per cell above an absolute threshold in the measurement report, where X is configured in reportConfig and the threshold in the measObject.
Additionally, the following has been argued to solve the problem and has been submitted to RAN2#100 in R2-1713427, which discusses corrections on RRM TP:                The current TP, the UE derives each cell quantity by the best N beams for that quantity as below:                    The UE shall:                            1> for each cell measurement quantity to be derived based on SS/PBCH block;                                    2> if nroSS-BlocksToAverage in the associated measObject is not configured; or                    2> if absThreshSS-BlocksConsolidation in the associated measObject is not configured; or                    2> if the highest beam measurement quantity value is below absThreshS S-BlocksConsolidation:                     3> derive each cell measurement quantity based on SS/PBCH block as the highest beam measurement quantity value, where each beam measurement quantity is described in TS 38.215 [FFS];                    2> else:                     3> derive each cell measurement quantity based on SS/PBCH block as the linear average of the power values of the highest beam measurement quantity values above absThreshSS-BlocksConsolidation where the total number of averaged beams shall not exceed nroSS-BlocksToAverage;                                                                                If multiple cell qualities (for example RSRQ and RSRQ) are configured to report, the UE may have different sets of best N beams for cell derivation considering the best N beams for RSRP and RSRQ may be different.        However, there has only one set of beams in measurement report, the current TP says the UE should include the best beam for each quantity, and other beams above the threshold in decreasing order, but it is unclear on how to sort these beams. If beams are sorted by different quantities (for example RSRP or RSRQ), the results would be different.                    For beam measurement information to be included in a measurement report the UE shall:                            1> set rsIndexResults to include up to maxNroRsIndexesToReport beam indexes in order of decreasing quantity as follows:                                    2> if the measurement information to be included is based on SS/PBCH block:                     3> include within resultsSSBIndexes the index associated to the best beam for that SS/PBCH block quantity and the remaining beams whose quantity is above absThreshSS-BlocksConsolidation defined in the VarMeasConfig for the corresponding measObject;                     3> if onlyReportBeamIds is not configured, include the SS/PBCH based measurement results associated to each beam index;                                                                                To clarify the beam raking criteria for beams report, one possible change is to sort the beams by the quantity triggered by the event, but it is still unclear on how to sort beams for periodical MR. another options is to indicate the quantity for beams sort explicitly by the network, in that case an additional configuration is needed to indicate the quantity for beam sort in MR.        Proposal 6: the network needs to indicate the measurement quantity for beam sort in measurement configuration if multiple quantities are configured to report.        
Thus, as it can be seen, the R2-1713427 contribution mentioned a first solution where that ‘triggerQuantity’ could be used as the measurement quantity to be used for sorting the beam level measurements to be reported. As it has been mentioned in the prior art itself, the problem with that solution is that the triggerQuantity is defined only for event triggered in the NR RRC specifications, hence, it is ambiguous how the UE shall sort the beams to be included in measurement reports.
Then, the Contribution suggests a second solution where an explicit parameter indicates the UE how to sort the beams, some kind of beam sorting reporting parameter. While that solution can solve the problem, that is not the most efficient.
The problems with the second solution are that an extra parameter would have to be defined in the specification and explicitly signalled to the UE. Also, another problem is that it only covers the case of a single trigger quantity i.e. report is triggered based on a single quantity RSRP, RSRQ or SINR. In NR, it has been at least proposed that the network should potentially configure multiple trigger quantities such as, for example, RSRP and RSRQ; RSRQ and SINR; RSRP and SINR; RSRP, RSRQ and SINR. Also, it has been proposed that these could be based on multiple RS types, e.g., SS/PBCH block and CSI-RS.
Yet another problem relates to the following agreements in NR, related to beam reporting associated to the serving cells. Specifically, in RAN2#99bis Prague, it has been agreed that beam level information (beam IDs and/or available measurement results) of the PCell/PSCell and SCell is included in the measurement report if the network has configured the UE to do so.
There is still an open question whether the UE always includes serving cells' beam information in measurement reports, although one of the alternatives might likely be supported:                UE shall include in measurement report all available beam measurement information for serving cell(s);        UE shall include in measurement report the available beam measurement information for serving cell(s) according to reportConfig associated to the report;        
In other words, in LTE, UE shall include RSRP and RSRQ in measurement reports for each configured serving cell. That has also been agreed for NR. Hence, as for each frequency there is a single serving cell, there is no need to solve the sorting problem for serving cell measurement reporting. However, in NR, it has been agreed that the network may configure the UE to include beam measurement results associated to i) serving cells (PCell and SCell(s)) and the ii) best neighbor(s) in serving frequencies as discussed above. Hence, the solution(s) described in the prior contribution and agreements ignore that aspect of serving cell measurements, which is yet another limitation.
Yet another problem relates to the following agreements in NR, related to beam reporting associated to the best neighbor cell(s) in each serving frequency. In RAN2#99bis Prague, it has been agreed that the network can configure the UE to report the best neighbour cells in the serving frequencies. The agreement from RAN2#99bis meeting allows for the cell level measurements of the best neighbour cell in serving frequencies to be included. However, the RSType to be used to perform the neighbour cell measurements is still not agreed. Though one can configure a separate information element to control what type of RSType to be used for performing the neighbour cell measurements in the serving frequencies, it would be sufficient to have the same RSType as the one used for the serving cells' measurements. It has already been agreed that the RSType for the serving cells' measurement is same as the one configured in the reportConfigNR. There is a possibility that the following may be agreed in NR:                UE shall use the same RSType(s) to measure best neighbour cell in the serving frequencies as that of serving cells' measurements in those frequencies.        
Like the RSType to be used for measuring the neighbour cell measurements in the serving frequencies, the quantities to be measured could also follow the same principles. It is beneficial to the network to have same quantity to be reported for the best neighbour cell and the serving cell in the serving frequencies so that the network can compare these measurements and take the decisions accordingly. As the RSRP and RSRQ measurements will always be reported for the serving cells, the same shall be applicable to the best neighbouring cells in those serving frequencies. The SINR reporting as mentioned in the previous section can be dependent on the contents of the report quantity of the measID that triggered the measurement report. Then, there is also a possibility that the following is also agreed in NR:                UE shall use the same measurement quantity for reporting cell level measurements of best neighbour cell in the serving frequencies as that of serving cells' measurements in those frequencies.        
The beam level information of the best neighbour cell in the serving frequencies is not always needed. In those cases when it is needed, the network can obtain the same by having specific events related to the same (e.g., A6 event). However, configuring additional A6 events just for the purpose of obtaining best neighbor cell beam level information in serving frequencies could lead to increase in the number of measurements as configured for the UE. In order to overcome this drawback, there could be a trade-off i.e. one could have the beam level information of the best neighbor cell in serving frequencies reported to the network only if the UE is configured with the beam level reporting is enabled in the reportConfig of the measID that triggered the measurement report. The following may also be agreed for NR:                UE shall include the beam level measurements of the best neighbour cell in the serving frequencies in the measurement report only if the beam level reporting is enabled in the reportConfig of the measID that triggered the measurement report.        
In order to further reduce the reporting overhead, the UE could report only those quantities that are configured in the beam level reporting related parameter in the reportConfig of the measID that triggered the measurement report.                shall include only those beam level measurement quantities of the best neighbour cell in the serving frequencies that are configured in the beam level reporting of the reportConfig in the measID that triggered the measurement report.        
In summary, beam level measurement information associated to best neighbor(s) in each serving frequency may also be configured by the network to be included by the UE in measurement reports. Hence, as that problem also did not exist in LTE or was not addressed by prior proposals, it still remains unsolved.